home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-avt-encodings-02.txt < prev    next >
Text File  |  1993-09-17  |  15KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Engineering Task Force          Audio-Video Transport Working Group
  8. INTERNET-DRAFT                                                H. Schulzrinne
  9. draft-ietf-avt-encodings-02.txt                       AT&T Bell Laboratories
  10.                                                           September 17, 1993
  11.                                                           Expires:  10/01/93
  12.  
  13.  
  14.                               Media Encodings
  15.  
  16.  
  17.  
  18. Status of this Memo
  19.  
  20.  
  21. This document is an Internet Draft.   Internet Drafts are working  documents
  22. of the Internet Engineering  Task Force (IETF), its  Areas, and its  Working
  23. Groups.   Note that other  groups may also  distribute working documents  as
  24. Internet Drafts.
  25.  
  26. Internet Drafts  are draft  documents valid  for a  maximum of  six  months.
  27. Internet Drafts may be  updated, replaced, or  obsoleted by other  documents
  28. at any time.   It  is not appropriate  to use Internet  Drafts as  reference
  29. material or to  cite them other  than as  a ``working draft''  or ``work  in
  30. progress.''
  31.  
  32. Please check  the I-D  abstract  listing contained  in each  Internet  Draft
  33. directory to learn the current status of this or any other Internet Draft.
  34.  
  35. Distribution of this document is unlimited.
  36.  
  37.  
  38.                                   Abstract
  39.  
  40.  
  41.      This  document describes a possible structure of the media content
  42.     for audio  and video  for Internet applications.    The definitions
  43.     are independent  of the particular  transport mechanism used.   The
  44.     descriptions  provide  pointers  to reference  implementations  and
  45.     the  detailed  standards.     This  document is  meant  as  an  aid
  46.     for implementors  of audio,  video  and other  real-time multimedia
  47.     applications.
  48.  
  49.  
  50. INTERNET-DRAFT       draft-ietf-avt-encodings-02.txt      September 17, 1993
  51.  
  52. 1 Audio
  53.  
  54.  
  55.  
  56. 1.1 Encoding-independent recommendations
  57.  
  58.  
  59. The  following  recommendations  are  default  operating  parameters.     An
  60. applications should  be  prepared  to  handle other  values.     The  ranges
  61. given  are  meant  to  give  guidance   to  application  writers,   allowing
  62. a set  of  applications  conforming  to  these  guidelines  to  interoperate
  63. without additional  negotiation.    These  guidelines are  not  intended  to
  64. restrict operating parameters for  application that can  negotiate a set  of
  65. interoperable parameters, e.g., through a conference control protocol.
  66.  
  67. For packetized  audio,  the default  packetization  interval should  have  a
  68. duration of 20 ms,  unless otherwise noted  in Table 1.   The  packetization
  69. interval determines the minimum end-to-end  delay; longer packets  introduce
  70. less header overhead but higher delay and make packet loss more  noticeable.
  71. For non-interactive  applications  such as  lectures  or links  with  severe
  72. bandwidth constraints, a higher packetization delay may be appropriate.  For
  73. frame-based encodings (marked as F in the  table 1 below) such as LPC,  CELP
  74. and GSM, the  sender may choose  to combine several  frame intervals into  a
  75. single message.  The receiver can  tell the number of frames contained in  a
  76. message since the frame duration is defined as part of the encoding.
  77.  
  78. If multiple channels are used, the left channel information always  precedes
  79. the right-channel information.  For  more than two channels, the  convention
  80. followed by the  AIFF-C audio  interchange format should  be followed.    It
  81. is listed in the  table below.   (The AIFF-C  specification is available  by
  82. anonymous ftp at ftp.sgi.com in the file sgi/aiff-c.9.26.91.ps.)
  83.  
  84.  
  85. type_______channels________________________________________________________________
  86.  
  87. stereo     left        right
  88. 3 channel  left        right        center
  89. quad       front left  front right  rear left  rear right
  90. 4 channel  left        center       right      surround
  91. 6 channel  left        left center  center     right       right center  surround
  92.  
  93.  
  94. The sampling frequency should be drawn from the set:  8, 11.025, 16,  22.05,
  95. 44.1 and 48 kHz.
  96.  
  97.  
  98. 1.2 Recommended Audio Encodings
  99.  
  100.  
  101. The table 1 shows the names, types (sample vs.  frame oriented), per-channel
  102. bit rates and default  sampling frequencies of recommended  encodings.   The
  103. list is  partially  drawn  from the  document  ``Recommended  practices  for
  104.  
  105. H. Schulzrinne                   Expires 10/01/93                   [Page 2]
  106.  
  107.  
  108. INTERNET-DRAFT       draft-ietf-avt-encodings-02.txt      September 17, 1993
  109.  
  110. enhancing digital audio compatibility in multimedia systems'', published  by
  111. the Interactive Multimedia Assocation, Version 3.00, Oct.  1992  (referenced
  112. as [IMA]). The  names are for  identification only;  they correspond to  the
  113. names used within the Real-Time Transport Protocol (RTP). Other applications
  114. may choose different namings.  Note  that the L16 encoding may be used  with
  115. different sampling rates.
  116.  
  117.  
  118.  
  119.   name  nom.  sampling   rate  type  frame  description
  120.  __________________kHz___kb/s__S/F___ms___________________________________
  121.   L16               48    768  S            16-bit linear, 2's complement
  122.                   44.1  705.6  S
  123.                  22.05  352.8  S
  124.                 11.025  176.4  S
  125.   G722              16     64  S            CCITT subband ADPCM
  126.   PCMU               8     64  S            CCITT mu-law PCM
  127.   PCMA               8     64  S            CCITT A-law PCM
  128.   G721               8     32  S            CCITT ADPCM
  129.   IDVI               8     32  S            Intel/DVI ADPCM [IMA]
  130.   G723               8     24  S            CCITT ADPCM
  131.   GSM                8     13  F     20     RTE/LTP GSM 06.10
  132.  _1016_______________8____4.8__F_____30_____CELP__________________________
  133.  
  134.  
  135.                          Table 1:  Audio encodings
  136.  
  137. For multi-octet  encodings, octets  are transmitted  in network  byte  order
  138. (i.e., most significant octet first).
  139.  
  140. A detailed description of  the encodings is  given below.   The names  shown
  141. (L16, PCMU, etc.)   are limited to four characters  and suitable to be  used
  142. for identification in protocols such as RTP (RFC TBD).
  143.  
  144.  
  145. L16: denotes  uncompressed audio  data, using  16-bit signed  representation
  146.     with 65535  equally divided  steps  between minimum  and maximum  signal
  147.     level, ranging from -32768 to 32767.  The value is represented in two's
  148.     complement notation.
  149.  
  150. PCMU: specified in  CCITT recommendation G.711.   Audio  data is encoded  as
  151.     eight  bits per  sample, after  companding.    Code to  convert  between
  152.     linear and mu-law companded data is available in the IMA document.
  153.  
  154. PCMA: specified in  CCITT recommendation G.711.   Audio  data is encoded  as
  155.     eight  bits per  sample, after  companding.    Code to  convert  between
  156.     linear and A-law companded data is available in the IMA document.
  157.  
  158. G721 through G729: specified  in  the corresponding  CCITT  recommendations.
  159.     Reference implementations for G.721  and G.723 are available as part  of
  160.     the CCITT Software Tool Library (STL) from the ITU  General Secretariat,
  161.     Sales Service, Place  du Nations, CH-1211 Geneve  20, Switzerland.   The
  162.  
  163. H. Schulzrinne                   Expires 10/01/93                   [Page 3]
  164.  
  165.  
  166. INTERNET-DRAFT       draft-ietf-avt-encodings-02.txt      September 17, 1993
  167.  
  168.     library is covered  by a license and is  available for anonymous ftp  on
  169.     gaia.cs.umass.edu, file pub/ccitt/ccitt_tools.tar.Z.
  170.  
  171. GSM: (group  speciale mobile)  denotes the  European GSM  06.10  provisional
  172.     standard  for full-rate  speech  transcoding,  prI-ETS  300  036,  which
  173.     is based  on RPE/LTP  (residual pulse  excitation/long term  prediction)
  174.     coding at a rate of 13 kb/s.  A reference implementation was  written by
  175.     Carsten Borman and Jutta  Degener (TU Berlin, Germany) and is  available
  176.     for anonymous ftp from tub.cs.tu-berlin.de, directory tub/tubmik.
  177.  
  178. 1016: uses  code-excited  linear  prediction  (CELP)  and  is  specified  in
  179.     Federal Standard  FED-STD 1016,  published by the  Office of  Technology
  180.     and Standards, Washington, DC 20305-2010.
  181.  
  182.     The  U. S.  DoD's  Federal-Standard-1016  based 4800  bps  code  excited
  183.     linear  prediction  voice coder  version  3.2  (CELP  3.2)  Fortran  and
  184.     C  simulation source  codes  are available  for  worldwide  distribution
  185.     at  no charge  (on  DOS diskettes,  but  configured  to compile  on  Sun
  186.     SPARC stations)  from:   Bob Fenichel,  National Communications  System,
  187.     Washington, D.C. 20305, phone +1-703-692-2124, fax +1-703-746-4960.
  188.  
  189.     Example  input  and processed  speech  files,  a  technical  information
  190.     bulletin, and  the official standard  ``Federal Standard 1016,  Telecom-
  191.     munications:   Analog  to Digital  Conversion of  Radio Voice  by  4,800
  192.     bit/second Code  Excited Linear Prediction (CELP)''  are included at  no
  193.     charge.  According  to Vincent Cate (Carnegie Mellon), the  distribution
  194.     is  also  available  for  anonymous  ftp  at   furmint.nectar.cs.cmu.edu
  195.     (128.2.209.111) in directory celp.audio.compression.
  196.  
  197.     The  following articles  describes  the  Federal-Standard-1016  4.8-kbps
  198.     CELP coder:
  199.  
  200.     Campbell, Joseph  P. Jr., Thomas  E. Tremain and  Vanoy C. Welch,  ``The
  201.     Proposed Federal  Standard 1016 4800  bps Voice Coder:   CELP,''  S_p_e_e_c_h_
  202.     T_e_c_h_n_o_l_o_g_y_ M_a_g_a_z_i_n_e_, April/May 1990, p.  58-64.
  203.  
  204.     Campbell, Joseph  P. Jr., Thomas  E. Tremain and  Vanoy C. Welch,  ``The
  205.     Federal  Standard 1016  4800  bps  CELP Voice  Coder,''  D_i_g_i_t_a_l_  S_i_g_n_a_l_
  206.     P_r_o_c_e_s_s_i_n_g_, Academic Press, 1991, Vol.  1, No.  3, p.  145-155.
  207.  
  208.     Campbell, Joseph  P. Jr., Thomas  E. Tremain and  Vanoy C. Welch,  ``The
  209.     DoD 4.8  kbps Standard (Proposed Federal  Standard 1016),'' in  A_d_v_a_n_c_e_s_
  210.     i_n_ S_p_e_e_c_h_  C_o_d_i_n_g_,  ed.   Atal,  Cuperman  and Gersho,  Kluwer  Academic
  211.     Publishers, 1991, Chapter 12, p.  121-133.
  212.  
  213.     Campbell, Joseph  P. Jr., Thomas  E. Tremain and  Vanoy C. Welch,  ``The
  214.     Proposed Federal  Standard 1016 4800  bps Voice Coder:   CELP,''  S_p_e_e_c_h_
  215.     T_e_c_h_n_o_l_o_g_y_ M_a_g_a_z_i_n_e_, April/May 1990, p.  58-64.
  216.  
  217.     Copies of the FS-1016 document are available for $2.50 each from:
  218.  
  219.  
  220.  
  221. H. Schulzrinne                   Expires 10/01/93                   [Page 4]
  222.  
  223.  
  224. INTERNET-DRAFT       draft-ietf-avt-encodings-02.txt      September 17, 1993
  225.  
  226.     GSA Rm 6654
  227.     7th & D St SW
  228.     Washington, D.C. 20407
  229.     1-202-708-9205
  230.  
  231.  
  232. DVI: is  specified in  the  ``Recommended  Practices for  Enhancing  Digital
  233.     Audio  Compatibility   in  Multimedia   Systems'',   published  by   the
  234.     Interactive Multimedia  Association (IMA), Annapolis,  MD. The  document
  235.     also contains reference implementations for mu-law to 16-bit,  ADPCM and
  236.     sample rate conversions.
  237.  
  238.  
  239.  
  240. For sample-based encodings,  a receiver should  accept packets  representing
  241. between 0 and  200 ms of  audio data.(1)   Receivers should  be prepared  to
  242. accept multi-channel audio, but may choose to only play a single channel.
  243.  
  244.  
  245. 1.3 Application Programming Interface for Audio Codecs
  246.  
  247.  
  248. The application programming interface (API) for audio codecs described  here
  249. is suggested, but not required for interoperability.  The API shown here  is
  250. similar to the one used by SunOS 4.1.  The encoding types are drawn from the
  251. standard names defined here.
  252.  
  253.  
  254. typedef {AE_PCMU = 1, AE_PCMA, AE_L16} encoding_t;
  255.  
  256. typedef struct {
  257.   unsigned sample_rate;            /* samples per second */
  258.   unsigned samples_per_unit;       /* samples per unit */
  259.   unsigned bytes_per_unit;         /* bytes per sample unit */
  260.   unsigned channels;               /* # of interleaved channels */
  261.   encoding_t encoding;             /* data encoding format */
  262.   unsigned data_size;              /* length of data (optional) */
  263. } audio_descr_t;
  264.  
  265. void *x_init(void *state, double period);
  266.  
  267. int x_encode(void *in_buf, int in_size, audio_descr_t *in_descr,
  268.    void *out_buf, int *out_size, void *state);
  269. int x_decode(void *in_buf, int in_size, audio_descr_t *out_descr,
  270.    void *out_buf, int *out_size, void *state);
  271.  
  272. ------------------------------
  273.  1. This restriction allows reasonable buffer sizing for the receiver.
  274.  
  275.  
  276.  
  277.  
  278.  
  279. H. Schulzrinne                   Expires 10/01/93                   [Page 5]
  280.  
  281.  
  282. INTERNET-DRAFT       draft-ietf-avt-encodings-02.txt      September 17, 1993
  283.  
  284. x_init initializes a particular instance  of a codec.  If the argument  state
  285. is zero, a memory area  sufficient to hold the  encoder or decoder state  is
  286. allocated; if that argument is non-zero, the existing area is reinitialized.
  287. The function returns a  pointer to the  area, zero if  the state area  could
  288. not be  allocated.    The argument  period refers  to  the amount  of  audio
  289. data in each  block, measured in  seconds.   It is  typically only used  for
  290. block-oriented codecs.
  291.  
  292. The generic pointer to state refers to an area of storage whose structure is
  293. opaque to the application program.  In the functions, 'x' is replaced by the
  294. appropriate codec name, appropriately modified to conform to C syntax (e.g.,
  295. g711, g721, etc).
  296.  
  297. The encoder and  decoder transform the  data contained in  the input  buffer
  298. in_buf (in_size bytes) and  deposit the  result into the  output buffer  area
  299. out_buf.    The variable  out_size  is set  to the  number of  bytes  actually
  300. contained in the output buffer.   The ah arguments points to a structure  of
  301. type audio_hdr_t,  which defines the given  input data format for the  encoder
  302. and the desired output data format for the decoder.  The functions return  0
  303. on success, a negative number if a failure occurred.
  304.  
  305. All block-oriented audio codecs should be able to encode and decode  several
  306. consecutive blocks.
  307.  
  308.  
  309.  
  310. 2 Video
  311.  
  312.  
  313. The following video encodings are defined, with their abbreviated names used
  314. for identification:
  315.  
  316.  
  317. Bolt: The encoding is  implemented by the Bolter video codec [ED: need  more
  318.     info on company, designation].
  319.  
  320. JPEG: The  encoding  is specified  in  ISO  Standards DIS  10918-1  and  DIS
  321.     10918-2.    The data  is  formatted according  to  the JFIF  (JPEG  File
  322.     Interchange Format) defined by C-Cube Microsystems.
  323.  
  324. H261: The encoding  is specified in ITU-T  (formerly CCITT) standard  H.261.
  325.     The packetization and RTP-specific properties are described in RFC TBD.
  326.  
  327. nv: The encoding is implemented in the program 'nv' developed at  Xerox PARC
  328.     by Ron Frederick.
  329.  
  330. CUSM: The  encoding is  implemented  in the  program CU-SeeMe  developed  at
  331.     Cornell University  by  Dick Cogger,  Scott Brim,  Tim Dorcey  and  John
  332.     Lynn.
  333.  
  334.  
  335.  
  336.  
  337. H. Schulzrinne                   Expires 10/01/93                   [Page 6]
  338.  
  339.  
  340. INTERNET-DRAFT       draft-ietf-avt-encodings-02.txt      September 17, 1993
  341.  
  342. PicW: The encoding is implemented in the program PictureWindow  developed at
  343.     Bolt, Beranek and Newman (BBN).
  344.  
  345.  
  346.  
  347. 3 Address of Author
  348.  
  349.  
  350. Henning Schulzrinne
  351. AT&T Bell Laboratories
  352. MH 2A244
  353. 600 Mountain Avenue
  354. Murray Hill, NJ 07974-0636
  355. telephone:  +1 908 582 2262
  356. facsimile:  +1 908 582 5809
  357. electronic mail:  hgs@research.att.com
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395. H. Schulzrinne                   Expires 10/01/93                   [Page 7]
  396.